Service flow with robust header compression (ROHC) in a WiMAX wireless network

ABSTRACT

A robust header compression (ROHC) controller provides for service flow processing of a ROHC channel in a WiMAX wireless communication system. The ROHC controller controls the negotiations of the MS ROHC capabilities during its registration and the negotiations of the ROHC channel parameters during ROHC enabled service flow setup; the MS ROHC capabilities including ROHC compression and decompression capabilities and ROHC channel and feedback strategies; the channel parameter negotiation covers the ROHC profile set and feedback channel information in addition to the 16e/12D standard. The ROHC controller receives a service flow request for a ROHC enabled service flow, wherein the request includes a QoS profile.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority pursuant to 35 USC §119(e) toU.S. Provisional Application Ser. No. 60/775,556, entitled “Method &Apparatus of WiMAX Robust Header Compression (“Multiplexing”), filedFeb. 22, 2006, and to U.S. Provisional Application Ser. No. 60/775,557,entitled “Robust Header Compression (ROHC) over WiMax,” filed Feb. 22,2006, each of which is hereby incorporated by reference herein in itsentirety.

BACKGROUND

1. Technical Field

The present invention relates generally to broadband wireless accessdata networks, and more particularly to data routing functionality forsuch data networks.

2. Related Art

Wireless data networks have provided mobile connectivity for subscribersunder fixed wireless and/or mobile wireless modes. Generally, fixedwireless access technology has evolved to provide “last mile”connectivity to households and/or businesses providing broadband datarates under IEEE §802.16d and IEEE § 802.16e specifications. In regionswithout pre-existing physical cable or telephone networks, suchtechnology may provide a viable alternative for broadband access.

For large-scale deployment, mesh networks require deployment of hundredsto thousands of mesh base transceiver stations, with each basetransceiver station requiring backhaul wire and/or optic fiber cableaccess to Internet networks and/or backbones. As a result, large numbersof cables have been needed for the backhaul access, incurring largedeployment costs in time, material, and labor. Further, such deploymentsincur data transmission delays associated with accessing the backhaulnetworks, undercutting the advantages that otherwise may have beenrealized by the bandwidth available by the mesh data network technology.

In general, a base transceiver station may provide backhaul data pathaccess from and to mobile stations and subscriber stations to an accessservice network gateway (ASN-GW) but needs to minimize these adversefactors. Further, the air links between a base transceiver station and amobile station is less than favorable for multimedia-rich datatransmissions, where transmission latency and the bit error rates ofsuch connections are less than optimal. Accordingly, a need exists forincreased performance of traffic over the air link between mobilestations and WiMAX base transceiver station.

SUMMARY

Provided is a method in a robust header compression (ROHC) controllerfor service flow provisioning of a ROHC wireless connection in a WiMAXwireless communication system.

Following registration of a mobile station with a WiMAX wirelesscommunication system, in which device capabilities are establishes witha base transceiver station, the ROHC controller of the respective device(which may be either the base transceiver station and/or the mobilestation) receives a service flow request for a ROHC enabled serviceflow, wherein the request includes a QoS profile. The ROHC controllerperforms a dynamic service addition (DSA) to create the ROHC channelbased upon the QoS profile. The ROHC negotiates the MS ROHC capabilitiesand ROHC channel parameters. With this information, a ROHC channel is inplace, and the ROHC controller compresses and decompresses the ROHCsessions within the ROHC enabled service flow and transmits via the ROHCchannel.

ROHC capability negotiations covers ROHC channel allocation strategy, itcan be one-to-one mapping to the conventional air link service flowchannel, or allocating one shared airlink channel for those ROHC enabledservice flows with the same QoS profile and to the same mobile station(MS). The negotiation also covers ROHC feedback strategy, dedicated orpiggybacking or interspersing. If it is dedicated, a one-to-one channelallocation is made for the feedback channel. ROHC channel parameterscovers ROHC channel profile set and feedback channel information, theseare to the current 16e/12D standard.

Other aspects and features of the present invention will become apparentto those ordinarily skilled in the art upon review of the followingdescription of specific embodiments of the invention in conjunction withthe accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram illustrating a wirelesscommunication network environment that includes circuit devices andnetwork elements and the operation thereof according to an embodiment ofthe invention;

FIG. 2 is a functional block diagram of a WiMAX base transceiver stationaccording to an embodiment of the invention;

FIG. 3 is a block diagram illustrating a front end processing module ofa WiMAX base transceiver station constructed according to an embodimentof the invention;

FIG. 4 is a block diagram illustrating a backhaul processing module of aWiMAX base transceiver station constructed according to an embodiment ofthe invention;

FIG. 5 is a block diagram illustrating a mobile station according to anembodiment of the invention;

FIG. 6 is a block diagram illustrating ROHC connections between a mobilestation and a WiMAX base transceiver station according to an embodimentof the invention;

FIG. 7 is a flow diagram illustrating the registration of a mobilestation with a WiMAX base transceiver station in accordance with anembodiment of the invention;

FIG. 8 illustrates a table containing information from the mobilestation registration with a base transceiver station in accordance withan embodiment of the invention;

FIG. 9 is a flow diagram illustrating an embodiment of service flowprocessing of a ROHC wireless connection or session in a WiMAX wirelesscommunication system.

FIG. 10 illustrates a state diagram 700 relating to operational modes ofa ROHC controller according to an embodiment of the invention; and

FIG. 11 is a state diagram relating to the decompressor statetransitions for the ROHC modes according to an embodiment of theinvention.

DETAILED DESCRIPTION OF THE DRAWINGS

It should be understood at the outset that although an exemplaryimplementation of one embodiment of the present disclosure isillustrated below, the present system may be implemented using anynumber of techniques, whether currently known or in existence. Thepresent disclosure should in no way be limited to the exemplaryimplementations, drawings, and techniques illustrated below, includingthe exemplary design and implementation illustrated and describedherein, but may be modified within the scope of the appended claimsalong with their full scope of equivalents. It is further understoodthat as used herein, terms such as “coupled”, “connected”, “electricallyconnected”, “in signal communication”, “communicatively coupled” and thelike may include direct connections between components, indirectconnections between components, or both, as would be apparent in theoverall context of a particular embodiment. The terms “transmit,”“transmitted,” or “transmitting” is intended to include, but not belimited to, the electrical transmission of a signal from one device toanother.

FIG. 1 is a functional block diagram illustrating a wirelesscommunication network environment 10 that includes circuit devices andnetwork elements and the operation thereof according to an embodiment ofthe invention. More specifically, a star topology zone 102 is a part ofthe network environment 10, which can include, by way of example, one ormore of a data network 160, an access service networks gateway (ASN-GW)162, a connectivity service network (CSN) 166, and a 3G radio accessnetwork (RAN) 164. The base transceiver stations operate under broadbandwireless access specifications such as WiMAX (that is, IEEE §802.16d forfixed wireless access and IEEE §802.16e for mobile wireless access), andsupport mesh access specifications (such as under IEEE §802.11s).

The broadband wireless communication network environment 10, via a startopology zone 102 that includes the mesh and wired base transceiverstations, operates to deliver broadband multimedia data ubiquitouslyover wireless links at multiples of the speed of traditionalcircuit-switched wireless systems, and over a far greater coverage areathan other wireless technologies (for example, IEEE §802.11 WiFitechnology). In this manner, the network environment 10 is designed todeliver wireless access at similar costs, but across tens of kilometersand realizing greater performance and higher data throughput. That is,in contrast to other wireless technologies, WiMAX is capable ofproviding high-bandwidth over distance, whereas WiFi (under IEEE §802.11specifications) may provide high bandwidth (but not distance), andcellular systems may provide distance, but not bandwidth.

Accordingly, the network environment 10 can provide users uninterruptedand untethered access to a variety of high-bandwidth services not onlyaround offices, homes, coffee shops, airports, and hotels, but also asusers roam in rural, suburban, and metropolitan settings.

In this manner, a plurality of wireless communication devices areillustrated as coupled to the wireless communication network environment10 to provide high-bandwidth services to users. The wirelesscommunication devices 20, 22 and 15, may be, by way of example, laptopcomputers 22 and 20, cellular telephones 15, and other wirelesscommunication devices, such as personal digital assistants 21, personalcomputers, et cetera. The details of the wireless communication networkenvironment 10 will be described in greater detail with reference toFIGS. 2 through 11.

The star topology zone 102 includes a plurality of mesh base transceiverstations 106-116, which are coupled to each other in a fixed wirelessconfiguration via wireless connections 180. Each of the mesh basetransceiver stations 106-116 are also in communication with the WiMAXbase transceiver station 104 through the wireless connections 180. TheWiMAX base transceiver station 104 provides a backhaul connection 182 tothe mesh base transceiver stations 106-116 for access to the datanetwork 160. The backhaul connection may be in the form of a wireless or“wired” (i.e., cable or fiber optic) connection.

In general, in a wirelessly-deployed mesh network, each of the basetransceiver stations have a backhaul connection 182 to the data network160 (such as an Internet backbone and/or a T1/E1 backhaul as well). Inthe star topology zone 102, a physical backhaul connection 182 isreplaced by a fixed wireless connection optimized to minimize the numberof hops to access the data network. In this manner, the cost andinefficiency of providing a physical backhaul connection 182 (such asthrough cables, fiber optics, et cetera) is minimized. The data network160 may be provided as an Internet protocol network or other form ofpacket data network capable of facilitating data communication betweenthe WiMAX base transceiver station 104 and the data network 160.

The wireless connections 180 may be provided under industry standardsspecification, such as IEEE §802.16d specification for fixed wirelessaccess and IEEE §802.16e for mobile wireless access upon which WiMAXtechnologies are based, as well as IEEE §802.11s for mesh-based wirelessaccess when applicable. Under the WiMAX standards specification, a basetransceiver station may provide up to seventy-five megabits per secondbandwidths up to a fifty-kilometer range. The radio frequency band underthe WiMAX specification is within 2.6 GHz and 5.8 GHz. Also, varioussignal modulation techniques may be used in the wireless channel, suchas QPSK (Quadrature Phase Shift Keying), BPSK (Binary Phase ShiftKeying), 16 QAM, 64 QAM, et cetera. Wireless connections 180 with themobile stations/subscriber stations 20, 21, and 22 are provided underthe mobility extension to the IEFE §802.16d specification (that is, theIEEE §802.16e specification). Accordingly, the wireless connectionsprovide the device and/or the users to transfer in and out of cellcoverage provided by each of the mesh base transceiver stations 106through 116, as well as the WiMAX base transceiver station 104.

In the wireless connections 180 may also be provided as WiMAX air links,robust header compression connections, and/or non-ROHC connections. Ingeneral, wireless connections 180 can be expensive and scarce resourcesthat tend to be lossy in nature, that have high bit error rates, longround-trip times, limited bandwidths, et cetera. With respect toreal-time service flows such as audio, voice, video, et cetera, suchwireless connections tend to be problematic. In these instances, ROHCcan mitigate the unfavorable characteristics of wireless. Robust headercompression facilitates the integration of an IP network with a wirelessnetwork of the broadband wireless configuration network environment 10.It also uses the bandwidth of the wireless connection efficiently byreducing header overhead. In effect, robust header compression improvesthe quality of the wireless connection.

As an example, voice datagrams, carried in a packet payload usingIPv6/UDP/RTP, have a size on the order of 20 bytes, while the headersize is on the order of 100 bytes. Robust header compression can achievesizes of one-to-four bytes, reducing the overhead in the present exampleby a factor of 100 and the total bandwidth consumption by a factor ofsix.

The use of ROHC channels, however, have not been addressed with respectto WiMAX air links, and the application of the former compression on aservice flow basis has been inefficient—extra overhead costs areincurred, reducing the performance of ROHC, and increasing the cost ofthe products. Accordingly, the ROHC mechanism provided in as QoS-based,allowing minimizing the management and data path overhead for WiMAXdevices to support ROHC transmission links. Further discussion regardingimplementation of ROHC in the communication network environment 10 isdiscussed in detail with reference to FIGS. 2 through 11.

The data network 160 is coupled to the access service networks gateway162 via a gateway connection 186. The access service networks gateway162 is a subscriber access gateway that facilitates communications withthe star topology zone 102 and that also concentrates subscriber trafficfrom peer-based transceiver stations 104 through 116. The primaryresponsibilities of the access service networks gateway 162 is toprovide mobility services to mobile IP and simple Internet protocol useraccess devices and processing of subscriber-controlled bearer traffic.The access service networks gateway 162 couples to a wireless accessnetwork, such as a 3G radio access network 164, via radio access network(“RAN”) connection 188.

The 3G radio access network may be provided under wireless transmissionstandards, including, for example, 1×EV-DO (Evolution Data Only,Evolution Data Optimized), W-CDMA (Wideband Code Division MultipleAccess), UMTS (Universal Mobile Telecommunications System), LTE (LongTerm Evolution), SAE (System Architecture Evolution), et cetera. Ingeneral, 3G refers to next generation wireless technologies extendedbeyond personal communication services. Further iterations of suchnetworks are anticipated, such as 4G, which serves as a successor of 3Gand further includes data transmissions supporting multimedia messaging,mobile TV, high definition TV content, DVB and minimal services, such asvoice and data at any time and any place. The term 4G is also referredto as 3G and beyond.

The access service networks gateway 162 is also coupled to aconnectivity service network via Connectivity Service Network (“CSN”)connection 190 which may access the connectivity service network 166 viaa home agent based network. Connectivity service network 166 providesservice features, such as services authorization, IP host configurationmanagement, and tunneling between the wireless communication device andthe connectivity service network 166.

Further provided, via the connection 190, from the connectivity servicenetwork 166 is mobility management for the wireless communication devicebetween base transceiver stations. In general, the connectivity servicenetwork 166, via the star topology zone 102, provides subscribers withsuch services as dynamic host configuration protocol (“DHCP”) server,often occasion, authorization and accounting (“AAA”), file transferprotocol (“FTP”), inter-operator and inter-technology roaming and othersuch services. The star topology zone 102 may be organized andstructured through operations, administration and maintenance (“OA&M”)functionality to facilitate the entry and removal of its constituentmesh base transceiver stations.

As noted, the broadband wireless communication network environment 10provides increased bandwidth and coverage for support of multimediaapplications that include multiple forms of information content andinformation processing (for example, text, audio, graphics, animation,video, interactivity) to inform and/or entertain a user. Nevertheless,as the amount of users increase, or the data size associated with a formof multimedia content increases, data compression is used to avoidovertaxing network resources. When the network resources are overtaxed,then multimedia application performance may suffer and frustrate usersof the technology. Also, other routing technologies may be employed,affecting the processing and routing of data packet headers, which areused for conveying or transporting a data payload to a user over thenetwork environment 10.

In this regard, the wired base transceiver station, providing WiMAX andmesh communications, creates uplink and downlink service flow data pathsthat can be configured to support various packet transmission formats.Further, to increase data throughput, the wired base transceiver stationprovides distributed processing functionality for front end and backhaulprocessing.

FIG. 2 is a functional block diagram of a WiMAX base transceiver station104. The WiMAX base transceiver station 104 is based upon amulti-processor design for increased throughput and processingcapability for the data packets routed via the base transceiver station.The base transceiver station 104 includes a radio 201, a front endprocessing module 202, a high-speed Ethernet switch module 208, and abackhaul processing module 210.

The radio 201 includes radio frequency units 203, 205, and 207. Thephysical layer module 203 provides for mobile WiMAX wireless datacommunications under IEEE §802.16e, the physical layer module 205provides for fixed WiMAX wireless data communications under IEEE§802.16d, and the physical layer module 207 provides for wireless meshdata communications under IEEE §802.11s. As wireless communicationspecifications change, evolve, or are otherwise added, the physicallayer module 201 may similarly include other radio interfaces toaccommodate varying wireless communications specifications.

The radio 201 allows data to be received from and sent to the WiMAX basetransceiver station 104. For data received from the physical layermodule 201, (for example, inbound data), the physical layer module 201provides the data 209 to the front end processing module 202 for furtherprocessing and/or routing to the backhaul processing module 210 via thepackets 211 routed by the high-speed Ethernet switch module 208. Theradio 201 is discussed in further detail with reference to FIG. 3.

The front end processing module 202 may include mobile wireless accessMAC (media access control) modules 204 and fixed wireless access MACmodules 206. The mobile wireless access MAC module 204 provides mobilewireless communications over the wireless connection 180 tomobile/subscriber stations (MS/SS) according to the IEEE §802.16especification. The fixed wireless access MAC module 206 providescommunications with subscriber stations and the backhaul networkaccording to the IEEE §802.16d specification, and/or the IEEE §802.11smesh specification, accordingly.

The front end processing module 202 provides MAC functionalityincluding, without limitation, over-the-air-provisioning such as airlink resource scheduling, air link channel management, MS/SS and BTSmessaging, et cetera. The front end processing module 202 also includesan executable physical layer and radio frequency software code tosupport wireless connection 180, such as for WiMAX air links, ROHCconnections, and/or non-ROHC connections.

The high-speed Ethernet switch module 208 switches packet traffic 211between the front end processing module 202 and the backhaul processingmodule 210. A suitable rate capacity for packet transfer is one gigabitper second (such as that set out under the IEEE §802.3z specification).

The backhaul processing module 210 is communicatively coupled to ASN-GW162 through a backhaul connection 182. The backhaul processing module210 operates to process the packets of traffic through the WiMAX basetransceiver station 104. The creation and configuration of data paths isdiscussed in detail with reference to FIGS. 3 through 11.

FIG. 3 is a block diagram illustrating the front end processing module202 constructed according to an embodiment of the invention. The frontend processing module 202 supports a plurality of heterogeneous physicallayer modes (for example, IS-95A, IS-95B, IS-2000, GSM-EDGE and/orvarious 3G and 4G standards specifications that are compatible with theteachings herein).

The front end processing module 202 includes front end processingcircuitry 302, dynamic RAM 306, static RAM 308, EPROM 310, and at leastone data storage device 312, such as a hard drive, optical drive, tapedrive, et cetera. These components (which may be contained on aperipheral processing card or module) intercouple such that the memorycontents are available to the front end processing circuitry 302. Thehigh-speed Ethernet switch interface 320 communicatively couples thefront end processing module 202 to the backhaul processing module 310via the high-speed Ethernet switch module 208.

The MAC modules 204, 206, and 326 couple to the front end processingcircuitry 302 via the radio frequency (RF) units 203, 205, and 207,respectively, to provide front end functionality to the WiMAX basetransceiver station 104. Each of these digital signal processing modules204, 206, and 326 perform digital signal processing for a respectivesectors (for example, sector one, sector two, or sector three) servicedby the base transceiver station 104 under the appropriate mobilewireless and/or fixed wireless access specifications.

The MAC module 204 supports mobile wireless access under the IEEE§802.16e specification. The MAC module 206 supports fixed wirelessaccess under the §802.16d specifications. The MAC module 326 supportswireless data access under the §802.11 specifications, such as the802.11s mesh specification. Thus, each of the digital processing modules204, 206, and 326 will perform some or all of the processing operationsdescribed with reference to FIGS. 9 through 11.

The MAC modules 204, 206, and 326 may be implemented by the front endprocessing circuitry and operational instructions stored in memories205, 208, 310 and/or 312. The front end processing circuitry 302 may beimplemented in logic, in operational instructions via software, or acombination of technologies to accommodate timing and/or responserequirements of the MAC modules 204, 206, and 326 and the PHY modules203, 205, and 206.

The RF units 203, 205, and 207 couple to antennas 340, 342, and 344,respectively, and support wireless communication between the WiMAX basetransceiver station 104 and the mobile and/or fixed terminals via theMAC modules 204, 206, and 326, respectively. The RF units 203, 205 and207, operating as physical layer modules, provide digital basebandtransmission processes based upon configuration signals from the MACmodules. The RF units attend to the transmission of the raw bit stream,defining parameters such as data rates, modulation method, signalingparameters, transmitter/receiver synchronization, et cetera.

The functional logic provided by the front end circuitry may be ashardware, software, firmware, or a combination thereof, implementedusing application specific integrated circuits (“ASIC”) orsystems-on-chips (where variations may include gate array ASIC design,full-custom ASIC design, structured ASIC design, et cetera), applicationspecific standard products (“ASSP”), programmable gate array (“PGA”)technologies (such as system programmable gate arrays (“SPGA”), fieldprogrammable gate arrays (“FPGA”)), digital signal processors (“DSP”),et cetera.

Structures and operational instructions regarding robust headercompression are stored in storage 312. The service flow managementoperational instructions are downloaded to the front end processingcircuitry 302 and/or the DRAM 306 for execution by the processor 302.While the ROHC operational instructions are shown to reside withinstorage 312 within the front end processing module 202, the ROHCoperational instructions may also be loaded onto portable media such asmagnetic media, optical media, or electronic media. Further, the serviceflow management 314 structure and/or operational instructions may beelectronically transmitted from one computer to another across a datacommunication path.

Upon execution of the operational instructions and structures regardingthe service flow management 314, the front end processing module 202performs operations according to the methods and processes describedherein with reference to FIGS. 1 through 11. Further, the structure ofthe WiMAX base transceiver station 104 illustrated is only one of thevaried base station structures that could be operated according to thedescriptions contained herein.

FIG. 4 is a block diagram illustrating the backhaul processing module210 constructed according to an embodiment of the invention. Thebackhaul processing module 210 includes backhaul processing circuitry352, dynamic RAM 356, static RAM 358, EPROM 360, and at least one datastorage device 362, such as a hard drive, optical drive, tape drive, etcetera. These components (which may be contained on a peripheralprocessing card or module, and consolidated into a lesser number ofcomponents than described above) intercouple to provide data resourcesto the backhaul processing circuitry 352.

Communicatively coupled to the backhaul processing circuitry 352 is ahigh-speed Ethernet switch interface 370, which communicatively couplesthe backhaul processing module 210 to the front end processing module202 via the high-speed Ethernet switch module 208 to provide transfer ofpacket traffic 211. Also coupled to the backhaul processing circuitry352 is a network infrastructure interface 372, which communicativelycouples the backhaul processing module 210 via a backhaul connection 182with an ASN-GW 162 (such as via the data network 160 of FIG. 1) and theOAM entities for the WiMAX base transceiver station 104.

The functional logic provided by the backhaul processing circuitry maybe as hardware, software, firmware, or a combination thereof,implemented using application specific integrated circuits (“ASIC”) orsystems-on-chips (where variations may include gate array ASIC design,full-custom ASIC design, structured ASIC design, et cetera), applicationspecific standard products (“ASSP”), programmable gate array (“PGA”)technologies (such as system programmable gate arrays (“SPGA”), fieldprogrammable gate arrays (“FPGA”)), digital signal processors (“DSP”),et cetera.

Structures and operational instructions regarding the protocol stack 364are stored in storage 362. The protocol stack 364 is downloaded to thebackhaul processing circuitry 352 and/or the DRAM 356 as the ROHCoperational instructions 354 for execution by the processor 352. Whilethe protocol stack is shown to reside within storage 362 within thebackhaul processing module 210, the protocol stack may also be loadedonto portable media such as magnetic media, optical media, or electronicmedia. Further, the ROHC operational instructions 364 may beelectronically transmitted from one computer to another across a datacommunication path.

Upon execution of the operational instructions and structures regardingthe ROHC 354, the backhaul processing module 210 performs operationsaccording to the methods and processes described herein with referenceto FIGS. 1 through 11. Further, the structure of the WiMAX basetransceiver station 104 illustrated is only one of the varied basestation structures that could be operated according to the descriptionscontained herein.

FIG. 5 is a block diagram illustrating a mobile station 20-22 thatperforms the operations previously described herein. The mobile station20-22 supports standardized operations that are compatible with theteachings of the disclosure, with or without modification. In otherembodiments, however, the mobile station 20-22 may support otheroperating standards.

The mobile station 20-22 includes an RF unit 502 implementing a physicallayer such as IEEE §802.16e, a digital processor 504, and a memory 506.The RF unit 502 couples to an antenna 518 that may be located internalor external to the case of the mobile station 20-22. The digitalprocessor 504 may be an Application Specific Integrated Circuit (ASIC)or another type of processor that is capable of operating the mobilestation 20-22.

The memory 506 includes both static and dynamic components, for example,dynamic RAM, static RAM, ROM, EEPROM, et cetera. In some embodiments,the memory 506 may be partially or fully contained upon an ASIC thatalso includes the processor 504.

A user interface 508 includes a display 510, a keyboard 512, aspeaker/microphone 514, and a data interface 516, and may include otheruser interface components. The RF unit 502, the digital processor 504,the memory 506, and the user interface 508 couple via one or morecommunication buses/links. A battery 510 also couples to and powers theRF unit 502, the digital processor 504, the memory 1008, and the userinterface 1010.

Operational instructions of the robust header compression 520 are storedin memory 522. The operational instructions of the ROHC 522 aredownloaded to the processor 504 as ROHC 520 for execution by the digitalprocessor 504. The ROHC 520 may also be partially executed by the RFunit 502 in some embodiments. The ROHC 520 may be programmed into themobile station 20-22 at the time of manufacture, during a serviceprovisioning operation, such as an over-the-air service provisioningoperation, or during a parameter updating operation. Upon execution, theoperational instructions of the ROHC 520 cause the mobile station 20-22to perform operations according to the present invention previouslydescribed with reference to the mobile stations of FIGS. 1 through 11.

The structure of the mobile station 20-22 illustrated is only an exampleof one mobile station structure. Many other varied mobile stationstructures could be operated according to the teachings of the presentdisclosure. Upon execution of the ROHC 520, the mobile station 20-22performs operations according to the present invention previouslydescribed herein in servicing a wireless connection 180.

FIG. 6 is a block diagram illustrating wireless connections between amobile station 20-22 and a base transceiver station 104-116. The mobilestation 20-22 includes a ROHC controller 528, a medium access control(MAC) layer 534 and a physical layer (PHY) 502. The ROHC controller 528includes a ROHC compressor 530 and a ROHC decompressor 532. The mobilestation 20-22 processes packet data content, such as via RTP/UDP/IPdataflow 524 and/or a UDP/TCP/IP dataflow 526, for user playback and/orinteraction via the user interface 508 (see FIG. 5), or for userinteraction to the network via the base transceiver station 104-116.

In general, the mobile station 20-22 and the base transceiver station104-116 are capable of routing ROHC service flows on QoS serviceclassifiers. That is, the bandwidth and other channel characteristicsmay be adjusted to accommodate similarly classified service flows,instead of creating dedicated ROHC channels for each of the ROHC enabledservice flows. That is, the management overhead is reduced, and theability to manage the WiMAX airlink channels 558.

The base transceiver station 104-116 includes a ROHC controller 542, amedium access control (MAC) layer 550, and a physical (PHY) layer 203.The base transceiver station 104-116. The ROHC controller 528 includes aROHC compressor 530 and a ROHC decompressor 532. A RTP/UDP/IP headerdataflow 538 and/or a UDP/TCP/IP header dataflow 540 are received andtransmitted by the mobile station 20-22 for playback to a user via theuser interface 508 (see FIG. 5). The ROHC controller 528 and the ROHCcontroller 542 provide highly-robust and efficient header compressionfor packets implementing RTP/UDP/IP (Real-Time Transport Protocol, UserDatagram Protocol, Internet Protocol) headers.

In general, UDP (User Datagram Protocol) is a transport layer protocolused by applications including the Domain Name System (DNS), streamingmedia applications (such as IPTV), Voice over IP (VoIP), Trivial FileTransfer Protocol (TFTP), online games, et cetera.

The Real-time Transfer Protocol (RTP) provides a packet format fordelivering audio over the Internet. The protocol is used in streamingmedia systems (in conjunction with the Real-time Streaming TransferProtocol (RSTP)) as well as videoconferencing and push to talk systems(such as with H.323 or Session Initiation Protocol). Applications usingRTP are less sensitive to packet loss, but typically very sensitive todelays.

The mobile station 20-22, via the ROHC controller 528, and the basetransceiver station 104-116, via the ROHC controller 542, accepts andtransports speech and/or video data streams over a WiMAX airlink 558.The WiMAX airlink 558 may be provided as a non-ROHC connection 556 or aROHC connection 554. The determination of whether to transport data overthe WiMAX air link 558 as either a non-ROHC connection 556 or a ROHCconnection 554 is based upon a flow classification that is QoS-based.

Generally, the ROHC connection 554 is created for service flows havinglatency sensitive data or high bandwidth data such as audio, visual,and/or multimedia data. In this regard the mobile station 20-22 and thebase transceiver station 104-116 provide an ROHC instance (that is, anROHC compressor instance or a ROHC decompressor instance). Either themobile station 20-22 or the base transceiver station 104-116 mayinitiate, through a dynamic service request (either as a dynamic serviceaddition or a dynamic service change), for an ROHC connection 554.

Also, multiple ROHC enabled service flows may be transported across theROHC channel 554, as well as having the channel 554 dedicated toindividual ROHC enabled service flow. Therefore, the ROHC controller 528and/or ROHC controller 542 may use a distinct context identifier spaceper channel. The ROHC controllers 528 and 542 may also eliminate contextidentifiers completely for one of the streams when few streams share aROHC connection 554.

The ROHC channel 554 is formed between an ROHC compressor 530 and a ROHCdecompressor 548. The ROHC compressor since transformed ROHC packetsthrough a logical point-to-point connection dedicated to that traffic.In this manner, the compressors and decompressors provide aunidirectional ROHC across the ROHC channel 554. The ROHC uplink flow563 extends from the compressor side to the decompressor side (in thisexample, mobile station 20-22 to the base transceiver station 104-116)by using the ROHC channel 554.

The ROHC feedback channel 561 extends from the decompressor side to thecompressor side (in this example, the base transceiver station 104-116to the mobile station 20-22) by using a dedicated channel orpiggybacking/interspersing on an associated ROHC compressor channel inthe reverse direction. When used, the ROHC feedback channel 561(interspersed, piggybacked, et cetera) provides with the ROHC channel554 the associated ROHC channels 560.

With respect to ROHC compression, different ROHC compression statesexist, in which compression state decisions are made on informationrelayed on feedback from the decompressor via the feedback service flow561 and periodic timeouts (such as when operating in a unidirectionalmode, that is, simplex channels or when the feedback service flow 561 isnot enabled)). The feedback provides information such as variations inpacket headers, positive feedback from decompressor (such asacknowledgments (ACKs)), negative feedback from the decompressor (suchas negative ACKs ((NACKs)).

Similar, with respect to the operations above, an ROHC channel mayextend from a base transceiver station 104-116 to a mobile station 20-22in a WiMAX networking environment. That is, the ROHC channel mayoriginate from the ROHC compressor 546 to the ROHC decompressor 532 ofmobile station 20-22, with an associated feedback channel when used.

FIG. 7 is a flow diagram illustrating the registration of a mobilestation 20-22 with a base transceiver station 104-116. The mobilestation 20-22 provides a registration request 572 to the basetransceiver station 104-116. The base transceiver station MAC 550receives the request 572 and provides the information via a mobilestation ROHC capability message 574 to the base transceiver station ROHCcontroller 542. The mobile station ROHC capability 574 includesinformation indicating whether the ROHC is supported by the mobilestation 20-22, and manner in which to implement the ROHC channel andfeedback channel, ROHC feedback strategy, et cetera. The basetransceiver station MAC 550 provides a request response message 576 tothe mobile station 20-22 indicating successful registration with thebase transceiver station 104-116, and the negotiation of robust headercompression capabilities that may be provided.

Upon registration, the ROHC capabilities are resolved between thedevices, either of the mobile station in 20-22 or the base transceiverstation 104-116 or the network side (such as the access servicenetwork/connectivity service network (ASN/CSN)) may initiate aROHC-based service flow.

FIG. 8 illustrates a table 580 containing information from the mobilestation registration with a base transceiver station. Generally, thetable 580 may include additional information or various table structuresadaptable to particular memory devices implemented in a base transceiverstation, such as on local, remote, or distributed devices, storage orother applicable network devices.

The first column 582 providing mobile station identifiers for the mobilestations that have registered with the base transceiver station. Thesecond column 584 contains information regarding the inability of amobile station to engage in robust header compression. The column 586,contains information regarding the feedback capabilities, and the mannerin which the feedback is to be provided. For example, feedback can beprovided as a piggyback onto other ROHC compressed packets, or asinterspersed packets within ROHC compressed packets or may be evenprovided as a dedicated feedback via a dedicated feedback channel.

Columns 587 and 589 relate to the way or allocation of the ROHC channeland the feedback channel, respectively. The allocation may be on aone-to-one basis (dedicated) or on a one-to-many basis (aggregated), andmay differ between the channels.

The ROHC negotiation provides for establishing ROHC capability betweenWiMAX devices regarding feedback strategy, ROHC channel negotiation etcetera. In general, as one of ordinary skill in the art may appreciate,ROHC channel parameters are negotiated during service flow setup. Whenthe mobile station is ROHC-capable and a service flow within the deviceenables ROHC operation, then the channel parameters for ROHC operationare implemented. Examples of service flow generation and/or creation isdiscussed in detail with reference to U.S. application Ser. No.11/618,555, entitled “Data Path Creation for WiMAX Base TransceiverStation with Backhaul Access,” filed Dec. 29, 2006, which is herebyincorporated herein by reference.

The ROHC channel negotiation (that is, capabilities) may be provided viaa message subheader technique or special TLV (Time-Length-Value)definitions. Message subheaders convey mobile station ROHC capabilities(compression, decompression or both) and feedback strategies (dedicated,piggyback, interspersing) in a WiMAX environment.

These ROHC parameters can also be conveyed through special TLV(Time-Length-Value) definitions; however, WiMAX specifications aregenerally silent with respect to specifics of ROHC establishment in theWiMAX communication environment.

For example, a WiMAX special Time-Length-Value (TLV) definition, definesa bit for the “TLV type 7” (piggyback feedback messages on forwardpackets) of “REG-REQ/REG-RSP” messages indicating whether there ismobile station support ROHC for IP (version 4 and/or version 6) packets.But other ROHC capability and/or characteristics for ROHC channelchannels are not provided, such as whether the airlink service flowchannel 558 identified by CID is used as the ROHC channel, or whetherone ROHC channel is allocated for all the ROHC enabled service flows inthe same direction and with the same QoS and to the same mobile station(that is, airlink channel aggregation). Also not addressed are feedbackstrategies. That is, a feedback uses a feedback airlink channel, whetherpiggybacks and intersperses only applicable to bidirectional serviceflows, et cetera.

With respect to the ROHC channel parameters, WiMAX specificationsaddress some special TLVs definitions that are communicated via DSx_REQmessages (that is, messages used to initiate WiMAX transactions). SuchTLV definitions indicate an ROHC service flow support for IP (v4 and v6)packets; and provides a TLV in the DSx_REQ messages for large context IDspace negotiation. Another TLV in the DSx_REQ messages provides forsmall context ID space. The WiMAX specification, however, does notaddress the negotiation of ROHC profiles for the ROHC channel and ROHCfeedback channel IDs.

FIG. 9 illustrates a method 600 in a robust header compression (ROHC)controller (ROHC) for service flow processing of a ROHC wirelessconnection or session in a WiMAX wireless communication system.

Beginning at step 602, a mobile station registers with a WiMAX basetransceiver station, wherein registration includes negotiating ROHCcapabilities with respect to a quality of service (QoS) service profilefor a desired ROHC channel. When at step 604 the desired ROHC channel isan aggregated airlink service flow channel, the ROHC controller at step605 receives a service flow request for a ROHC enabled service flow,wherein the request includes the QoS service profile. The QoS serviceprofile indicates the nature of the payload contents and the priority ofthe payload with respect to delay sensitivity, bandwidth, et cetera. Therequest may be initiated by a mobile station 20-22 or a base transceiverstation 110-116.

At step 606, a service flow request is provided for an ROHC enabledservice flow. The ROHC controller determines whether the desired ROHCservice flow exists based upon the QoS service profile within therequest. In other words, whether the desired ROHC channel for the ROCHenabled service is pre-existing.

When, at step 606, such an ROHC service flow exists, then at a step 608,the ROHC controller retrieves a corresponding ROHC channel, and performsa dynamic service change (DSC) to modify the existing ROHC channelparameters, as needed, at step 610. At step 612, with the existing ROHCchannel parameters modified as needed at step 610, the service flow istransmitted via the existing ROHC channel with modified parameters.

When, at step 606, such a service flow does not exist, then at step 614the ROHC controller performs a dynamic service addition (DSA) to createa new ROHC channel in a unidirectional ROHC mode. At step 616 ROHCcontroller receives an ROCH channel for the service flow, and negotiatesat step 618 the ROHC parameters for the new ROHC channel. With the newROHC channel, the ROHC controller transmits the service flow via the newROHC channel at step 620.

Through the method of FIG. 9, a mobile station communicating with a basetransceiver station can have a different service flow and the mobilestation can change its service flow according to the available resourcesof that WiMAX system.

FIG. 10 illustrates a state diagram 700 relating to operational modes ofa ROHC controller for ROHC profile 1 and profile 2 for the compressor.The operational modes include a unidirectional ROHC mode 702, anoptimistic ROHC mode 704, and a reliable ROHC mode 706. Each of themodes 702, 704, and 706, include an IR compression state, a first ordercompression state, and a second order compression state.

In general, the optimal mode that a ROHC controller operates depends onthe characteristics of the environment of the compression protocol, suchas feedback abilities, error probabilities and distributions, effects ofheader variation, et cetera.

In the unidirectional ROHC mode 702 services flows are sent in onedirection only, from the compressor to the decompressor. This modetherefore makes robust header compression usable over links where afeedback service flow from decompressor to compressor is unavailable orundesirable.

Compression with ROHC begins with the unidirectional ROHC mode 702.Transition to any of the bidirectional modes 704 and 706 can beperformed when a packet of the service flow reaches the decompressor,and the decompressor replies with a feedback packet indicating that amode transition is desired.

The bidirectional optimistic ROHC mode 704 is similar to theunidirectional ROHC mode 702. The difference is that a feedback sendserror recovery requests and acknowledgments of significant contextupdates from the decompressor to compressor. The bidirectionaloptimistic ROHC mode 704 operates to reduce the number of damagedheaders delivered to the upper layers due to residual errors or contextinvalidation. The frequency of context invalidation may be higher thanfor reliable ROHC mode 706, in particular when long loss/error burstsoccur.

The bidirectional reliable ROHC mode 706 makes intensive usage of thefeedbacks and a stricter logic at both the compressor and thedecompressor to prevent loss of context synchronization betweencompressor and decompressor. Feedback is sent via the feedback channelto acknowledge all context updates, including updates of the sequencenumber field.

In general, ROHC compression can be characterized as an interactionbetween a compressor and a decompressor, each interaction occurring onceper context. The compressor and the decompressor each have three states.Both the compressor and the decompressor start in the lowest compressionstate and transit gradually to higher states.

With respect to the compressor states, the compressor operates in thehighest possible compression state, under the constraint that thecompressor is sufficiently confident that the decompressor has theinformation necessary to decompress a header compressed according tothat state.

The purpose of the Initialization and Refresh (IR) State is toinitialize the static parts of the context at the decompressor or torecover after failure. In this state, the compressor sends completeheader information. This includes all static and nonstatic fields inuncompressed form plus some additional information. The compressor staysin the IR state reasonably confident that the decompressor has receivedthe static information correctly.

The purpose of the First Order (FO) compressor states are to efficientlycommunicate irregularities in the packet stream. When operating in thisstate, the compressor rarely sends information about all dynamic fields,and the information sent is usually compressed at least partially. Onlya few static fields can be updated. The difference between IR and FOshould therefore be clear.

Under the Second Order (SO) state, the header compression is optimal.The compressor enters the SO state when the header to be compressed issubstantially predictable given the RTP Sequence Number (SN), and thecompressor is sufficiently confident that the decompressor has acquiredall parameters of the functions from SN to other fields. Correctdecompression of packets sent in the SO state only hinges on correctdecompression of the SN. Successful decompression, however, alsorequires that the information sent in the preceding FO state packets hasbeen successfully received by the decompressor.

FIG. 11 is a state diagram relating to the decompressor statetransitions for the ROHC modes 702, 704, and 706 of FIG. 1 for profile 1and profile 2. The state machine includes a no context state 812, astatic context state 814, and a full context state 816. The ROHCcontroller starts the decompressor in its lowest compression state, “NoContext” state 812 and gradually transits to higher states. Thedecompressor state machine generally does not leave the “Full Context”state 816 once it has entered this state.

Underlying operation and mechanisms relating to robust headercompression and decompression are discussed in further detail in “RObustHeader Compression (ROHC): Framework and four profiles: RTP, UDP, ESP,and uncompressed,” IETF Request For Comment 3095 (July 2001).

In the manner provided herein, a ROHC enabled service flow and ROHCsessions within this service flow may be implemented between a mobilestation and base transceiver station via a QoS service profile.Accordingly, provisioning of ROHC service flows are provided such thatmultiple service flows may be accommodated within an ROHC channel overthe airlink with ROHC service flow aggregation with the same QoSparameters and to the same mobile station, either utilizing existingROHC service flows, or creating additional ROHC service flows as needed;or ROHC channel maps to the service flow airlink channel in one-to-onerelationship, therefore there is no aggregation.

The embodiments of the invention disclosed herein are susceptible tovarious modifications and alternative forms. Specific embodimentstherefore have been shown by way of example in the drawings and detaileddescription. It should be understood, however, that the drawings anddetailed description thereto are not intended to limit the invention tothe particular form disclosed, but on the contrary, the invention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present invention as defined by the claims.

What is claimed is:
 1. A method for service flow processing of a ROHCwireless connection or session in a robust header compression (ROHC)controller of a WiMAX wireless communication system comprising:registering a mobile station with a WiMAX base transceiver station,wherein registration includes negotiating ROHC capabilities; receiving aservice flow request for a ROHC enabled service flow, wherein therequest includes a Quality of Service (QOS) service profile that isindicative of a priority and contents of a payload conveyed on a desiredROHC channel; wherein in response to a determination that the desiredROHC channel is an aggregated airlink service flow channel: determiningwhether the desired ROHC channel exists based upon the QoS serviceprofile; and wherein in response to a determination that the desiredROHC channel exists, retrieving the existing ROHC channel; performing adynamic service change (DSC) to modify parameters of the existing ROHCchannel; and transmitting the service flow via the existing ROHC serviceflow with modified parameters; wherein in response to a determinationthat the desired ROHC channel does not exist: performing a dynamicservice addition (DSA) to create a new ROHC channel; receiving the newROHC channel; negotiating ROHC parameters related to the new ROHCchannel; and transmitting the service flow via the new ROHC channel. 2.The method of claim 1, wherein when the desired ROHC channel is aone-to-one air link service flow channel: receiving a service flowrequest for a ROHC enabled service flow, the service flow requestincluding ROHC channel parameters; and establishing an airlinkunidirectional channel for the ROHC enabled service flow based upon thechannel parameters to carry the ROHC enabled service flow, the ROHCenabled service flow including a plurality of ROHC sessions anduncompressed sessions.
 3. The method of claim 1 wherein the ROHC channelhas a feedback channel when a feedback is negotiated based upon thenegotiated ROHC capabilities.
 4. The method of claim 3 furthercomprises: upon detecting the feedback, transitioning from aunidirectional ROHC mode to a bidirectional ROHC mode for the ROHC. 5.The method of claim 4 wherein the bidirectional ROHC mode comprises atleast one of a bidirectional optimistic ROHC mode and a bidirectionalreliable ROHC mode.
 6. The method of claim 5 wherein each of theunidirectional ROHC mode, bidirectional optimistic ROHC mode and thebidirectional reliable ROHC mode has a context state indicating ROHCcompression and decompression information.
 7. The method of claim 6wherein the context state includes at least an initialization andrefresh, a first order, and a second order compressor state, andincludes at least a no context, a static content, and a full contentdecompressor state, wherein each state relates to a respectivecompression level and decompression level.
 8. The method of claim 1wherein negotiating ROHC channel parameters related to the ROHC channelcomprises: extracting ROHC channel parameters from a ROHC channelparameters extended subheader; and comparing the extracted ROHC channelparameters with supported ROHC channel parameters; and selecting theROHC channel parameters common to both the extracted ROHC channelparameters and the supported ROHC channel parameters.
 9. The method ofclaim 1 wherein negotiating the ROHC capabilities comprises: extractinga special TLV (Time-Length-Value) definition; and comparing theextracted ROHC capabilities with supported ROHC capability parameters;and selecting the ROHC capability parameters common to both theextracted ROHC capability parameters and the supported ROHC capabilityparameters.
 10. The method of claim 1 wherein negotiating ROHC channelparameters comprises: extracting ROHC channel parameters from at leastone DSx message; comparing the extracted ROHC channel parameters withsupported ROHC channel parameters; and selecting the ROHC channelparameters common to both the extracted ROHC channel parameters and thesupported ROHC channel parameter.
 11. The method of claim 1 wherein theROHC channel has a feedback channel when a wireless reverse channel ispresent.
 12. A mobile station of a WiMAX wireless network includingservice flow processing of a ROHC wireless channel and sessions withinthe channel in the WiMAX wireless network, the mobile stationcomprising: a user interface; a radio frequency (RF) unit that providesan interface between the mobile station and at least one basetransceiver station of the wireless network; at least one digitalprocessor coupled to the RF unit and the user interface; and memorycoupled to the at least one digital processor, wherein the memory storesoperational instructions, which when executed cause the digitalprocessor to: in response to a determination that a desired ROHC channelis an aggregated airlink service flow channel: receive a service flowrequest for a ROHC enabled service flow, wherein the request includes aQuality of Service (QOS) service profile that is indicative of apriority and contents of a payload conveyed on a desired ROHC channel;determine whether the requested ROHC service flow exists based upon theQoS service profile; and wherein in response to a determination that theROHC channel exists: retrieve a corresponding ROHC channel; perform adynamic service change (DSC) to modify ROHC channel parameters of theROHC channel; and transmit the service flow via the existing ROHCchannel including modified ROHC channel parameters; wherein in responseto a determination that the ROHC channel does not exist: perform adynamic service addition (DSA) to create a new ROHC channel; receive thenew ROHC channel; negotiate ROHC channel parameters related to the newROHC channel; and transmit the service flow via the new ROHC channel.13. The mobile station of claim 12, wherein when the desired ROHCchannel is a one-to-one to air link service flow channel, the memoryfurther stores operational instructions that further cause the at leastone digital processor to: receive a service flow request for a ROHCenabled service flow, the service flow request including ROHC channelparameters; and establishing an airlink unidirectional channel for theROHC enabled service flow based upon the ROHC channel parameters tocarry the ROHC enabled service flow, the ROHC enabled service flowincluding a plurality of ROHC sessions and uncompressed sessions. 14.The mobile station of claim 12 wherein the ROHC channel includes afeedback channel when a feedback is negotiated based upon the negotiatedROHC capabilities.
 15. The mobile station of claim 12, wherein thememory further stores operational instructions that further cause the atleast one digital processor to: upon detecting feedback packets,transition from a unidirectional ROHC mode to a bidirectional ROHC modefor the ROHC.